


Minutes from LEGO Rock Raiders Internal Meeting 


Date: 1S' June 1998. 


Attendees: lan Deary, Tony Stoddart, Rob Dorney, Rob Wilson, Simon Scott. 





AL 


Object Swapping with Relation to Direct X Format 


It was noted that the current system of using Direct X files for all the in-game objects is inefficient 
for two main reasons: 


1.1 It is not currently possible to load animation data contained within an X file without 


1) 


loading all the objects contained within that file. The animation data can not be used 
for other objects. 


Consequences: 

Instead of having one animation file that can be used for the five different minifigures, each 
animation would have to be duplicated four times by the artists thus creating multiple scenes 
and X files. All of the X files would have to be loaded at the beginning of the game thus 
creating a long loading time at the beginning of each level; or loaded during game which 
would cause the game to pause. (This would be more applicable to upgraded objects). 
With the minifigures this would currently lead to approximately 180 individually named 
objects, 250 Lightwave files and 250 X files of which none of the X files are editable without 
recreating them. With so many files the chances of mistakes becomes greater. 


Possible Solutions 

(a) Replace all the objects within a scene file with generically named Null objects that have 
no path data. Use these Null objects as targets for the required mesh object. This 
system is currently used for positioning wheels in both the ‘Kart’ game and ‘LEGO Rock 
Raiders’. 

(b) Extract all the data directly form Lightwave scene files that should also be quicker to load. 


It is not currently possible to duplicate the animation data without loading another X 
file. 


Consequences: 
Every time a new object appears on the screen, even if it is identical to one already on the 


screen, all the data has to be loaded again for multiples. 


Possible Solutions 

(a) lmplement a hot swapping system that uses animation data that is loaded once and used 
for all variants. (See item 1.1) 

(b) Determine what speed increases would be gained from using Lightwave scene files more 
directly. 


2) Lava and Water 


It was brought to everybody’s attention that little thought has been placed into any technical 
solution of how fluids will be represented in the game. It was discussed that the current 
blocks that constitute the terrain along with objects at the head of a flow could be a possible 
solution. 


3) 


9) 


It was decided that everybody should consider this aspect of the game while continuing work 
on higher priority tasks. 


Documentation pertaining to the current ideas on how lava and water operate in the game 
can be obtained on request from ID. 


Minifigure Poly Counts and Vehicle/Building Poly Counts and Animation 


It was mentioned that the poly count for the minifigure object was unsatisfactory and a closer 
look at these files and animation sets would be required. RD has looked at this problem and 
modified the object and scene files on Mother. 


It was decided that the priority for the artists should be the satisfactory completion of all the 
high and low poly objects that are currently contained within the design document. It was 
decided that this should take no longer than two weeks. 


RD is currently compiling a detailed list of all objects, poly counts and animations done to this 
date. 


In-game Object Scale 


It was discussed that some of the objects in the game are much larger than others. For 
example the screen space taken by a minifigure in relation to the Large Helicopter. It was 
suggested that this may pose problems both aesthetically and technically with respect to 
collision. It was suggested that some objects might be better with different scale values. 
However, ID suggested this may not be agreeable to LEGO and that before anything else is 
done on this subject all the objects will have to be placed on a block so see how they work 
with our current game scale. This is also necessary to determine how larger vehicles will be 
able to move around a base without collision becoming difficult. 


Programming Time Scale 


It was agreed by all present that the programming of the game is in danger of falling behind 
schedule. Steps must be taken to identify possible pitfalls and assist RW in his coding work. 





Update on Item 1 (02/06/98) 


RW has informed us that the system of using Null objects within a scene file has been 
unsuccessful. He is currently working on object swapping code. However, he fears that the only 
way to solve this problem will be to have an individual scene file and X file for every action and for 
every minifigure which would increase loading times. 


